Method and apparatus for resolving client-side logic

ABSTRACT

A computer implemented method, an apparatus, and a computer usable program product for rendering client-side logic in a webpage when the webpage is rendered is provided. A webpage development framework initiates a script component built in a component library of a webpage development framework, wherein the script component is subject to a lifecycle of the webpage development framework. The webpage development framework defines at least one webpage attribute using at least one value-binding expression in the script component, wherein the at least one value-binding expression provides access to a server-side data model. The webpage development framework then evaluates the at least one value-binding expression, wherein the at least one value-binding expression comprises a current value for the server-side data model.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to an improved data processingsystem, and in particular to a method an apparatus for rendering awebpage. Still more specifically, the present invention provides acomputer implemented method, an apparatus, and a computer usable programproduct for resolving client-side logic in a webpage when the webpage isrendered.

2. Description of the Related Art

Client-side logic is a set of computer usable program code or computerinstructions that is executed in a client computer. For example, in awebpage, client-side logic executes the processes for presenting awebpage to the client who requested the page. Client-side logic can alsobe used to execute processes within the webpage, such as the effects ofa client pressing a button or hitting a hyperlink in the webpage.

Typically, client-side logic is resolved when a webpage is built orcreated on the server that supports the webpage. When a request for awebpage is made by a client, the server supporting the webpage processesthe request. When processing the request, the server resolves or assignsvalues for each attribute that the client-side logic defines. Thus, if aclient-side logic defines a button on the webpage, the values associatedwith the button are determined by the server prior to sending theresponse to a client.

A webpage development framework is an application in a server thatprocesses a client's request for a webpage. A webpage developmentframework allows a web developer to create a new webpage as well as tomanage the new webpage. An example webpage development framework isJavaServer™ Faces.

In a webpage development framework, a request is subject to thelifecycle of the framework. The lifecycle is typically the differentsteps or stages used to process a request for a webpage. In a lifecycle,a period of time typically exists between when a page is built and whenthe webpage is actually rendered or presented to a user. Typically,values for an attribute are assigned no later than when the webpage isbuilt in the webpage development framework. Therefore, any changes in avalue received in the time period between when a webpage is built andwhen the webpage is rendered is not included in the response to theclient's request.

SUMMARY OF THE INVENTION

A computer implemented method, an apparatus, and a computer usableprogram product for rendering client-side logic in a webpage when thewebpage is rendered is provided. A webpage development frameworkinitiates a script component built in a component library of a webpagedevelopment framework, wherein the script component is subject to alifecycle of the webpage development framework. The webpage developmentframework defines at least one webpage attribute using at least onevalue-binding expression in the script component, wherein the at leastone value-binding expression provides access to a server-side datamodel. The webpage development framework then evaluates the at least onevalue-binding expression, wherein the at least one value-bindingexpression comprises a current value for the server-side data model.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 is a pictorial representation of a network of data processingsystems, in which illustrative embodiments may be implemented;

FIG. 2 is a block diagram of a data processing system, in whichillustrative embodiments may be implemented;

FIG. 3 illustrates a script component in a JavaServer™ Faces frameworkin a data processing system, in accordance with an illustrativeembodiment of the present invention;

FIG. 4 depicts an example of scripting language in a script component,in accordance with an illustrative embodiment; and

FIG. 5 illustrates the process for resolving client-side logic in awebpage when the webpage is rendered, in accordance with an illustrativeembodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments may be implemented. It shouldbe appreciated that FIGS. 1-2 are only exemplary and are not intended toassert or imply any limitation with regard to the environments in whichdifferent embodiments may be implemented. Many modifications to thedepicted environments may be made.

With reference now to the figures, FIG. 1 depicts a pictorialrepresentation of a network of data processing systems in whichillustrative embodiments may be implemented. Network data processingsystem 100 is a network of computers in which embodiments may beimplemented. Network data processing system 100 contains network 102,which is the medium used to provide communication links between variousdevices and computers connected together within network data processingsystem 100. Network 102 may include connections, such as wire, wirelesscommunication links, or fiber optic cables.

In the depicted example, server 104 and server 106 connect to network102 along with storage unit 108. In addition, clients 110, 112, and 114connect to network 102. These clients 110, 112, and 114 may be, forexample, personal computers or network computers. In the depictedexample, server 104 provides data, such as boot files, operating systemimages, and applications, to clients 110, 112, and 114. Clients 110,112, and 114 are clients to server 104 in this example. Network dataprocessing system 100 may include additional servers, clients, and otherdevices not shown.

In the depicted example, network data processing system 100 is theInternet with network 102 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, network data processing system 100 also may be implemented as anumber of different types of networks, such as for example, an intranet,a local area network (LAN), or a wide area network (WAN). FIG. 1 isintended as an example, and not as an architectural limitation fordifferent embodiments.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which illustrative embodiments may be implemented.Data processing system 200 is an example of a computer, such as server104 or client 110 in FIG. 1, in which computer usable code orinstructions implementing the processes may be located for theillustrative embodiments.

In the depicted example, data processing system 200 employs a hubarchitecture including a north bridge and memory controller hub (MCH)202 and a south bridge and input/output (I/O) controller hub (ICH) 204.Processing unit 206, main memory 208, and graphics processor 210 arecoupled to north bridge and memory controller hub 202. Processing unit206 may contain one or more processors and even may be implemented usingone or more heterogeneous processor systems. Graphics processor 210 maybe coupled to the MCH through an accelerated graphics port (AGP), forexample.

In the depicted example, local area network (LAN) adapter 212 is coupledto south bridge and I/O controller hub 204 and audio adapter 216,keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224,universal serial bus (USB) and other communications ports 232, andPCI/PCIe devices 234 are coupled to south bridge and I/O controller hub204 through bus 238, and hard disk drive (HDD) 226 and CD-ROM drive 230are coupled to south bridge and I/O controller hub 204 through bus 240.PCI/PCIe devices may include, for example, Ethernet adapters, add-incards, and PC cards for notebook computers. PCI uses a card buscontroller, while PCIe does not. ROM 224 may be, for example, a flashbinary input/output system (BIOS). Hard disk drive 226 and CD-ROM drive230 may use, for example, an integrated drive electronics (IDE) orserial advanced technology attachment (SATA) interface. A super I/O(SIO) device 236 may be coupled to south bridge and I/O controller hub204.

An operating system runs on processing unit 206 and coordinates andprovides control of various components within data processing system 200in FIG. 2. The operating system may be a commercially availableoperating system such as Microsoft® Windows® XP. Microsoft and Windowsare trademarks of Microsoft Corporation in the United States, othercountries, or both. An object-oriented programming system, such as theJava™ programming system, may run in conjunction with the operatingsystem and provides calls to the operating system from Java programs orapplications executing on data processing system 200. Java and allJava-based trademarks are trademarks of Sun Microsystems, Inc. in theUnited States, other countries, or both.

Instructions for the operating system, the object-oriented programmingsystem, and applications or programs are located on storage devices,such as hard disk drive 226, and may be loaded into main memory 208 forexecution by processing unit 206. The processes of the illustrativeembodiments may be performed by processing unit 206 using computerimplemented instructions, which may be located in a memory such as, forexample, main memory 208, read only memory 224, or one or moreperipheral devices.

The hardware in FIGS. 1-2 may vary depending on the implementation.Other internal hardware or peripheral devices, such as flash memory,equivalent non-volatile memory, or optical disk drives and the like, maybe used in addition to or in place of the hardware depicted in FIGS.1-2. Also, the processes of the illustrative embodiments may be appliedto a multiprocessor data processing system.

In some illustrative examples, data processing system 200 may be apersonal digital assistant (PDA), which is generally configured withflash memory to provide non-volatile memory for storing operating systemfiles and/or user-generated data. A bus system may be comprised of oneor more buses, such as a system bus, an I/O bus and a PCI bus. Of coursethe bus system may be implemented using any type of communicationsfabric or architecture that provides for a transfer of data betweendifferent components or devices attached to the fabric or architecture.A communications unit may include one or more devices used to transmitand receive data, such as a modem or a network adapter. A memory may be,for example, main memory 208 or a cache such as found in north bridgeand memory controller hub 202. A processing unit may include one or moreprocessors or CPUs. The depicted examples in FIGS. 1-2 and theabove-described examples are not meant to imply architecturallimitations. For example, data processing system 200 also may be atablet computer, a laptop computer, or a telephone device in addition totaking the form of a PDA.

A computer implemented method, an apparatus, and a computer usableprogram product for rendering client-side logic in a webpage when thewebpage is rendered is provided. A webpage development frameworkinitiates a script component built in a component library of a webpagedevelopment framework, wherein the script component is subject to alifecycle of the webpage development framework. The component librarycomprises a set of computer usable program code currently existing inthe webpage development framework.

The lifecycle of the webpage development framework includes restoring aview of a webpage requested by a client. The step of restoring is eitherbuilding a new view or building a last presented view of the webpage.The second step of the lifecycle is to apply a last presented value foreach attribute in the view. The last presented value is a value of theat least one attribute when the webpage was last rendered. The next stepof the lifecycle is to validate the last presented value for eachattribute in the view against the validation rules. The validation rulesdefine the data type to be input into each attribute. The next step ofthe lifecycle includes updating the last presented value for eachattribute. The webpage development framework obtains the current valuefrom a server-side data model.

The webpage development framework defines at least one webpage attributeusing at least one value-binding expression in the script component. Theat least one value-binding expression provides access to a server-sidedata model. To provide access, the at least one value-binding expressionbinds a value in the at least one value-binding expression to aserver-side data model.

The webpage development framework evaluates the at least onevalue-binding expression. The at least one value-binding expressionincludes a current value for the server-side data model. In response toevaluating the value-binding expression, the webpage developmentframework determines whether a scripting language should be rendered. Inresponse to rendering the determination, the scripting language isrendered by extracting the current value from the server-side datamodel. The scripting language then inserts the current value into thevalue-binding expression. The rendering of the scripting language occurswhen a response to a request for a webpage is rendered.

FIG. 3 illustrates a script component in a JavaServer™ Faces frameworkin a data processing system, in accordance with an illustrativeembodiment of the present invention. Data processing system 300 is ahost server that stores, updates, and renders a webpage for at least onebusiness entity. Data processing system 300 can be implemented as aserver, such as server 104 or 106 of FIG. 1 or data processing system200 of FIG. 2. In the illustrative embodiment, data processing unit 300includes JavaServer™ Faces (JSF) framework 310, radiobutton component320, button component 322, and script component 330. JavaServer™ is atrademark of Sun Microsystems, Inc. in the United States, othercountries, or both. In the illustrative embodiment, all components indata processing unit 300 are implemented as software componentsexecutable in a processing unit, similar to processing unit 206 of FIG.2.

JSF framework 310 is a webpage development framework or a server-side,Web application framework for building Web-based user interfaces inJava™. In other words, JSF framework 310 facilitates web developers withthe development and management of a webpage. JSF framework 310 providesa set of standard components or attributes, including but not limited tobuttons, hyperlinks, and checkboxes. JSF framework 310 also provides aset of tags to refer to the standard attributes. A tag is a reference toa set of instructions that can be used as a short-cut in developing awebpage. In other words, instead of writing each and every line of codeto perform a particular function, a web developer can refer to thefunction, or the tag naming the function, to reference the set of code.JSF framework 310 allows a webpage developer to use existing tags aswell as to create custom tags which are unique to the webpage developer.Furthermore, JSF framework 310 provides additional attributes to processclient-based events or logic.

In the illustrative embodiment, JSF framework 310 includes JSF lifecycle312 and data model 314. JSF lifecycle 312 is a six-step process for JSFframework 310 to process Hypertext Transfer Protocol (HTTP) requests.Specifically, in the illustrative embodiment, the HTTP requests arerequests for a HyperText Markup Language (HTML) page, commonly known asa webpage.

The six-step process for JSF lifecycle 312 is (1) restore view; (2)apply request values; (3) process validations; (4) update model values;(5) invoke applications; and (6) render response. In the restore viewstep, JSF framework 310 either reconstructs a previously existingwebpage or creates the attributes required to build a new webpage. Inthe illustrative embodiment, a view is a user interface representationof the webpage. Thus, to restore the view, JSF framework 310 receives arequest from a client through a JSF servlet (not shown). The JSF servletmanages the lifecycle of the request for a webpage. Thus, the JSFservlet manages the processing of a request through JSF lifecycle 312and provides the resources needed by JSF framework 310 to process therequest. To process the request, the JSF servlet extracts a viewidentification from the request and identifies the attributes associatedwith the view identification. If the view identification exists and isnot a new webpage, then JSF framework 310 builds a view of the webpageusing the identified attributes. If, on the other hand, the viewidentification is a new webpage, then JSF framework 310 associatesinstructions or computer-usable program code to the attributes andprepares the view to be associated with the attributes. The codeassociated with attributes can include, for example, event handlers orvalidators.

In the apply request values step, JSF framework 310 applies the valuestransmitted in the request to each respective attribute in the view. Forexample, in the illustrative embodiment, consider a request from aclient that includes a text field in which the user inputs data. In theapply request values step, JSF framework 310 receives the request,extracts the value from the request, associates the value with therespective attributes, and then stores the value in the attributes. Inthis example, the value would be some form of text.

In the process validation step, the values within each attribute arevalidated against validation rules for JSF framework 310. In otherwords, JSF framework 310 ensures that the values entered into eachattribute are the correct type of value or are within a particularrange. For example, JSF framework 310 ensures that a date field ispopulated with a date instead of text or that a text field is populatedwith text instead of symbols. The validation rules are typicallyestablished by the developer of the webpage when the webpage isinitially created.

In the update model values step, JSF framework 310 updates the values ineach attribute with the values stored in data model 314. Data model 314is a server-side data structure and can be implemented using the mainmemory of data processing system 300, similar to main memory 208 of FIG.2. Data model 314 can be in any format, including but not limited to atable, a flat file, an Extensible Markup Language (XML) file, arelational database management system, or any combination thereof. Inthe illustrative embodiment, data model 314 is a table. In the updatemodel values step, JSF framework 310 updates the attributes with thevalues in the table in data model 314.

In the invoke application step, JSF framework 310 invokes theapplication to handle any form event. A form event is any action by auser that triggers a series of instructions or code in a webpage.Example form events include but are not limited to a user clicking alink or pressing a button in the webpage. A handler, or a set ofinstructions, is typically associated with the event. Thus, when a usertriggers the form event, the webpage initializes the handler to beginexecuting the instructions for processing the form event. In the invokeapplication step, JSF framework 310 ties an attribute to a handler foreach of the form events within each webpage.

In the render response step, JSF framework 310 creates a response andpresents the response with all the attributes in the updated state to auser. In the illustrative embodiment, to render means to present acompleted webpage to a client. The render response step occursimmediately before JSF framework 310 transmits or sends the response tothe user. Thus, in the illustrative embodiment, JSF framework 310presents the webpage that includes radiobutton component 320, buttoncomponent 322, and script component 330.

In the illustrative embodiment, radiobutton component 320 and buttoncomponent 322 are example attributes in the webpage and are presented astwo concentric circles and an “OK” button, respectively. Theillustrative embodiments are not limited to the illustrated components,but can be implemented as any other type of component, such as ahyperlink or a checkbox.

Script component 330 is an attribute that allows webpage developers towrite scripts that contain dynamic expressions. A script is a line ofcomputer logic or a single command in a computer program. A dynamicexpression is a script which utilizes data that changes over time. Thedata can be stored as values in data model 314 or in any other storagedevice within JSF framework 310, such as a managed bean. The script inscript component 330 defines the attribute represented by scriptcomponent 330.

In the illustrative embodiment, script component 330 allows for dynamicclient-side logic to be incorporated into a webpage. Client-side logicis a set of computer usable program code or script executed in a clientcomputer. Client-side logic is embedded in the webpage and transmittedto the user as part of the response to the client. Thus, client-sidelogic is executed at the time the webpage is displayed and presented tothe client. Client-side logic can be used to define an attribute or canbe an event handler for a form event. As an event handler, client-sidelogic executes when the form event, such as the pressing of a key or thehovering of a mouse over an image, occurs.

Script component 330 is part of the component library stored within JSFframework 310. A component library is a library of all the standardattributes available to a web developer when creating a webpage. Allcomponents within the component library are subject to JSF lifecycle312. Thus, when processing a request for a webpage, script component 330will go through all six steps of JSF lifecycle 312.

In the illustrative embodiment, script component 330 includes avalue-binding expression that defines the attribute represented byscript component 330. A value-binding expression is a dynamic expressionthat binds values stored in a storage device to the script that refersto the value. To bind means to establish a reference or a location wherethe data for a particular script can be found. In the illustrativeembodiment, the value-binding expression binds values stored in datamodel 314 to the script in script component 330.

Value-binding expressions are used when values are not available at thetime the webpage is developed. Thus, the value is only available orobtained when the expression is executed during runtime. Thus,value-binding expressions are used because the values within thevalue-binding expression cannot be hard-coded into script component 330.For example, in the illustrative embodiment, consider a webpage for abank. The bank would like to show an alert on an account to a customerwhen the customer's bank account is below a particular threshold. Inthis example, script component 330 contains a value-binding expressionthat triggers an alert in the webpage when the account is below thepreset threshold. The account balance is not a fixed value and changesover time. Thus, in this example, data processing system 300 cannotdetermine whether the account balance is below the threshold until theaccount balance is requested by the customer. Once the customer requeststhe account balance, data processing system 300 can execute thevalue-binding expression to determine the account balance. Once theaccount balance is determined, then data processing system 300 candetermine whether the account balance is below the threshold, and if so,trigger the alert for the customer.

In the illustrative embodiment, the value-binding expression is found inline 332. The text “dataModel” in line 332 refers to data model 314 andindicates that the current value for the value-binding expression is indata model 314. “wparType” is the specific class of data stored in datamodel 314 to which the value-binding expression refers. Thus, thevalue-binding expression in line 332 provides access to current valuesand data in data model 314. Therefore, when evaluating the value-bindingexpression, lifecycle 312 will extract current values from data model314 to be input into the value-binding expression. In an alternativeembodiment, “dataModel” can refer to a managed bean, and the managedbean can include the data included in data model 314. In yet anotherembodiment, instead of providing a value-binding expression, such asline 332, to be resolved at render time, script component 330 can use anexisting script stored in the component library.

In the illustrative embodiment, script component 330 also includesadditional script 335. Additional script 335 is rendered when thevalue-binding expression in script component 330 is evaluated. In otherwords, when script component 330 is initiated, the value-bindingexpression is evaluated or run. As part of evaluating the value-bindingexpression, additional script 335 is rendered or resolved. To resolve isto determine a value for a particular set of instructions. In theillustrative embodiment, a current value for additional script 335 isdetermined when additional script 335 is rendered or resolved. In theillustrative embodiment in line 337, the text “S” is the current valueof the class “wparType”.

In the illustrative embodiment, script component 330 resolves thevalue-binding expression as JSF framework 310 renders a response. Thus,in the illustrative embodiment, the render response step is athree-phase process: (1) create a response; (2) modify the response; and(3) present the response to a client. In the create a response phase,script component 330 initially evaluates the value-binding expressionbut does not resolve additional script 335. The evaluation onlyidentifies that additional script 335 needs to be resolved at a latertime. In the modify the response phase, additional script 335 is thenresolved, and, in the illustrative embodiment, the current value of “S”is input into the value-binding expression.

In one embodiment, additional script 335 actually inputs the currentvalue of “S” into the value-binding expression. In another embodiment, adetermination is made during the evaluation that additional script 335does not need to be resolved. Therefore, additional script 335 does notinput any current value into the value-binding expression. As an exampleof such a determination, consider the example illustrated above of abank triggering an alert for a customer if the account balance is belowa preset threshold. If the value-binding expression in script component330 determines that the account balance is above the threshold, thenadditional script 335 will not be resolved because additional script 335is the script for displaying the alert to the customer. Thus, additionalscript 335 would only resolve if the account balance was below thethreshold.

Thus, in use, in the illustrative embodiment, JSF framework 310 receivesa request for a particular webpage. JSF framework 310 processes therequest using JSF lifecycle 312. During the render response step, JSFframework 310 initiates instructions to build the webpage that includesradiobutton component 320 and button component 322. Additionally, JSFframework 310 initiates script component 330 to begin evaluating thevalue-binding expression in line 332. After the webpage is built, thenJSF framework 310 resolves the value-binding expression with additionalscript 335. Additional script 335 retrieves the value of “wparType” fromdata model 314 and enters the value “S” into the value-bindingexpression in script component 330. JSF framework 310 then transmits andpresents the completed webpage to the client.

The illustrative embodiments are not limited to the illustrativeexample. For example, data processing system 300 and JSF framework 310can include more or fewer components. Additionally, any webpagedevelopment framework other than JSF framework 310 may be used toprocess a request for a webpage.

FIG. 4 depicts an example of scripting language in a script component,in accordance with an illustrative embodiment. Scripting language 400can be implemented in script component 330 of FIG. 3. Scripting language400 is a set of instructions or code for establishing an identificationfor a specific component in a webpage. Specifically, the exemplifiedscript establishes an attribute identification for a wizard panel,referred to as “wizardPanelID” in line 410 of scripting language 400.Scripting language 400 is exemplary only and is not limited to theillustrative embodiment. In alternative embodiments, scripting language400 can define a number of other attributes as well.

In the illustrative embodiment, an attribute identification includes thename of the attribute and the location for the attribute in thecorresponding webpage. However, the attribute identification is notlimited to the illustrative embodiment and can include other informationas well. Attribute identifications change when a web designer changesthe format of a webpage and moves the attribute to another location oranother data model. The attribute identification can also change ifadditional attributes are added to the webpage and are associated withthe identification for the wizard panel.

The exemplified script includes the value-binding expression“value=”var#{utilityBean.portletNS}tPanel=ODCRegistry.getClientControl(‘#{pc_CreateWWizard.wizard PanelID}’, null);#{utilityBean.portletNS}tPanel.restoreUI State(‘#{pc_CreateWWizard.panelToExited}’)”, which is found in lines 410 and412. In the illustrative example, the value-binding expression isresolved when the webpage is rendered to the user.

Thus, in use for the illustrated example, a client requests a webpagefrom a webpage development framework, such as JSF framework 310 of FIG.3. During the render response step, the webpage development frameworkinitiates instructions to build the webpage which includes the wizardpanel attribute. The webpage development framework evaluates thevalue-binding expression for the wizard panel attribute. The webpagedevelopment framework initiates script component 400 and evaluates thevalue-binding expression in line 410. The webpage development frameworkthen builds the webpage and then resolves the value-binding expressionwith an additional script (not shown). The additional script then inputsthe current value into the value-binding expression in line 410 and thewebpage development framework then transmits and presents the completedwebpage to the user.

FIG. 5 illustrates the process for resolving client-side logic in awebpage when the webpage is rendered, in accordance with an illustrativeembodiment. The process may be implemented in a webpage developmentframework, such as JavaServer™ Faces Framework 310 of FIG. 3. Thefollowing process is exemplary only and the order of the steps may beinterchanged without deviating from the scope of the invention.

The process begins with the webpage development framework receiving arequest for a webpage (step 500). In these examples, the requestoriginates from a client process, such as a browser. The request maycome from other requesters, such as for example a web crawling processor some other server. The webpage development framework then restores aview of the webpage (step 510). To restore, the webpage developmentframework either builds a new view or builds a last presented view ofthe webpage. The last presented view of the webpage is the last webpagethat was presented to the client prior to the present request beingmade. The webpage development framework then applies a last presentedvalue for each attribute in the view (step 520). The last presentedvalue is a value of the attribute which was presented to the clientprior to the present request being made. The webpage developmentframework then validates the last presented value for each attributeagainst the validation rules (step 530). To validate, the webpagedevelopment framework determines the appropriate date type and datarange assigned to the attribute using the validation rules. Thevalidation step ensures that the last presented value was the correcttype of data and the correct range.

The webpage development framework then updates the last presented valuefor each attribute with a current value from a server-side data model(step 540). The webpage development framework then creates the responseto the request by building the webpage (step 550). Any value-bindingexpression in a script component is then evaluated (step 560). Thevalue-binding expression defines the attribute that the script componentrepresents. The webpage development framework then modifies the webpagebased on the script component (step 570). The script component thenresolves any additional script (step 580). The webpage developmentframework then presents the response to the user (step 590), with theprocess terminating thereafter.

Thus, a computer implemented method, an apparatus, and a computer usableprogram product for rendering client-side logic in a webpage when thewebpage is rendered is provided. A webpage development frameworkinitiates a script component built in a component library of a webpagedevelopment framework, wherein the script component is subject to alifecycle of the webpage development framework. The component librarycomprises a set of computer usable program code currently existing inthe webpage development framework.

The lifecycle of the webpage development framework includes restoring aview of a webpage requested by a client. The step of restoring is eitherbuilding a new view or building a last presented view of the webpage.The second step of the lifecycle is to apply a last presented value foreach attribute in the view. The last presented value is a value of theat least one attribute when the webpage was last previously rendered.The next step of the lifecycle is to validate the last presented valuefor each attribute in the view against the validation rules. Thevalidation rules define the data type to be input into each attribute.The next step of the lifecycle includes updating the last presentedvalue for each attribute. The webpage development framework obtains thecurrent value from a server-side data model.

The webpage development framework defines at least one webpage attributeusing at least one value-binding expression in the script component. Theat least one value-binding expression provides access to a server-sidedata model. To provide access, the at least one value-binding expressionbinds a value in the at least one value-binding expression to aserver-side data model.

The webpage development framework evaluates the at least onevalue-binding expression. The at least one value-binding expressionincludes a current value for the server-side data model. In response toevaluating the value-binding expression, the webpage developmentframework determines whether a scripting language should be rendered. Inresponse to rendering the determination, the scripting language isrendered by extracting the current value from the server-side datamodel. The scripting language then inserts the current value into thevalue binding expression. The rendering of the scripting language occurswhen a response to a request for a webpage is rendered.

Therefore, the illustrative embodiments provide a mechanism forincorporating values received subsequent to when a webpage is built.Furthermore, the illustrative embodiments provide for the values to beincorporated using a value-binding expression in a script component. Inthis manner, a user is able to view data that is current up to when thewebpage is rendered to the user.

The invention can take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. In a preferred embodiment, the invention isimplemented in software, which includes but is not limited to firmware,resident software, microcode, etc.

Furthermore, the invention can take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer-readable medium can be any tangibleapparatus that can contain, store, communicate, propagate, or transportthe program for use by or in connection with the instruction executionsystem, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system (or apparatus or device) or apropagation medium. Examples of a computer-readable medium include asemiconductor or solid state memory, magnetic tape, a removable computerdiskette, a random access memory (RAM), a read-only memory (ROM), arigid magnetic disk and an optical disk. Current examples of opticaldisks include compact disk-read only memory (CD-ROM), compactdisk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modems and Ethernet cards are just a few of thecurrently available types of network adapters.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A computer implemented method for rendering client-side logic in awebpage when the webpage is rendered, the computer implemented methodcomprising: initiating a script component built in a component libraryof a webpage development framework, wherein the script component issubject to a lifecycle of the webpage development framework; defining atleast one webpage attribute using at least one value-binding expressionin the script component, wherein the at least one value-bindingexpression provides access to a server-side data model; and evaluatingthe at least one value-binding expression, wherein the at least onevalue-binding expression comprises a current value for the server-sidedata model.
 2. The computer implemented method of claim 1, furthercomprising: responsive to evaluating the at least one value-bindingexpression, determining whether a scripting language should be rendered.3. The computer implemented method of claim 1, wherein the step ofevaluating the at least one value-binding expression comprises:rendering a scripting language that extracts the current value from theserver-side data model, wherein the scripting language inserts thecurrent value into the value-binding expression.
 4. The computerimplemented method of claim 3, wherein the step of rendering a scriptinglanguage resolves when a response to a request for the webpage isrendered.
 5. The computer implemented method of claim 1, wherein thelifecycle of the webpage development framework comprises: restoring aview of the webpage requested by a client, wherein the step of restoringcomprises at least one of building a new view and building a lastpresented view of the webpage; applying a last presented value for eachattribute in the view, wherein the last presented value is a value ofthe at least one attribute when the webpage was last rendered;validating the last presented value for the each attribute againstvalidation rules which define the data type to be input in the eachattribute; and updating the last presented value for the each attributewith a current value from the server-side data model.
 6. The computerimplemented method of claim 1, wherein the value-binding expressionproviding access to the server-side data model comprises: binding avalue in the at least one value-binding expression to the server-sidedata model.
 7. The computer implemented method of claim 1, wherein thecomponent library comprises a set of computer usable program codecurrently existing in the webpage development framework.
 8. A dataprocessing system comprising: a script component embedded in a webpage,wherein the script component is built in a component library of awebpage development framework, and wherein the script component issubject to a lifecycle of the webpage development framework, and whereinthe webpage development framework initiates the script component; atleast one webpage attribute defined using at least one value-bindingexpression in the script component; and the least one value-bindingexpression in the script component provides access to a server-side datamodel, wherein the webpage development framework evaluates the at leastone value-binding expression, and wherein the at least one value-bindingexpression comprises a current value for the server-side data model. 9.The data processing system of claim 8, wherein the webpage developmentframework determines whether a scripting language should be rendered inresponse to evaluating the value-binding expression.
 10. The dataprocessing system of claim 9, further comprising: the scripting languagecoupled to the script component, wherein the scripting language extractsa current value from the server-side data model in response to thescripting language being rendered, and wherein the scripting languageinserts the current value into the value-binding expression.
 11. Acomputer program product comprising a computer usable medium includingcomputer usable program code for rendering client-side logic in awebpage, the computer program product comprising: computer usableprogram code for initiating a script component built in a componentlibrary of a webpage development framework, wherein the script componentis subject to a lifecycle of the webpage development framework; computerusable program code for defining at least one webpage attribute using atleast one value-binding expression in the script component, wherein theat least one value-binding expression provides access to a server-sidedata model; and computer usable program code for evaluating the at leastone value-binding expression, wherein the at least one value-bindingexpression comprises a current value for the server-side data model. 12.The computer program product of claim 11, further comprising: responsiveto evaluating the value-binding expression, computer usable program codefor determining whether the scripting language should be rendered. 13.The computer program product of claim 11, wherein the computer usableprogram code for evaluating the at least one value-binding expressioncomprises: computer usable program code for rendering a scriptinglanguage that extracts the current value from the server-side datamodel, wherein the scripting language inserts the current value into thevalue-binding expression.
 14. The computer program product of claim 13,wherein the computer usable program code for rendering a scriptinglanguage resolves when a response to a request for the webpage isrendered.
 15. The computer program product of claim 11, wherein thelifecycle of the webpage development framework comprises: computerusable program code for restoring a view of the webpage requested by auser, wherein the step of restoring comprises at least one of building anew view and building a last presented view of the webpage; computerusable program code for applying a last presented value for eachattribute in the view, wherein the last presented value is a value ofthe at least one attribute when the webpage was last rendered; computerusable program code for validating the last presented value for the eachattribute against validation rules which define the data type to beinput in the each attribute; and computer usable program code forupdating the last presented value for the each attribute with a currentvalue from the server-side data model.
 16. The computer program productof claim 11, wherein the value-binding expression providing access tothe server-side data model comprises: computer usable program code forbinding a value in the at least one value-binding expression to theserver-side data model.
 17. The computer program product of claim 11,wherein the component library comprises a set of computer usable programcode currently existing in the webpage development framework.
 18. A dataprocessing system comprising: a means for initiating a script componentbuilt in a component library of a webpage development framework, whereinthe script component is subject to a lifecycle of the webpagedevelopment framework; a means for defining at least one webpageattribute using at least one value-binding expression in the scriptcomponent, wherein the at least one value-binding expression providesaccess to a server-side data model; and a means for evaluating the atleast one value-binding expression, wherein the at least onevalue-binding expression comprises a current value for the server-sidedata model.
 19. The data processing system of claim 18, furthercomprising: responsive to evaluating the at least one value-bindingexpression, a means for determining whether the scripting languageshould be rendered.
 20. The data processing system of claim 18, whereinthe means for evaluating the at least one value-binding expressioncomprises: a means for rendering a scripting language that extracts thecurrent value from the server-side data model, wherein the scriptinglanguage inserts the current value into the value-binding expression.